Applying Aspect-Oriented Programming to Intelligent Synthesis

I discuss a component-centered, aspect-oriented system, the Object Infrastructure Framework (OIF), NASA's initiative on Intelligent Synthesis Environments (ISE), and the application of OIF to the architecture of ISE. A critical issue in developing component-based and distributed systems is getting the assembled set of components to follow the policies of the overall system. To achieve ilities such as reliability , availability, responsiveness, performance, security, and manageability, all system components must consistently perform certain actions. Unfortunately, developers of off-the-shelf or pre-existing components, blithely unaware of or indifferent to these requirements, do not code the appropriate policy support. For custom components, the developers are likely to be domain experts, not experts in systems and distributed computing, and are similarly unlikely to consistently and correctly code the calls to ility support routines. Furthermore, policies change over a system's lifetime. Tracking these changes in the components will be difficult or (lacking the component source code) impossible. Separating out the specification and implementation of ili-ties and providing mechanisms for weaving together the main functionality with the ility code is a prime example of the potential leverage of aspect-oriented programming (AOP). In earlier papers, we described the Object Infrastructure Framework (OIF), a CORBA centered , aspect-oriented system for achieving ilities in distributed systems [4, 5]. OIF realized the following key ideas: 1. Intercepting communications. OIF intercepted and manipulated communications among functional components, invoking appropriate " services " on these calls. Semantically , this is equivalent to wrapping or filtering [1] on both the client and server side of a distributed system. The next five points can be understood as describing the architecture of a flexible wrapping system. 2. Discrete injectors. Our communication interceptors are first class objects: discrete components that have (object) identity and are invoked in a specific sequence. We call them injectors. In a distributed system, an ility may require injecting behavior on both the client and the server. (Figure 1 illustrates injectors on communication paths between components .) Injectors are uniform so we can build utilities to manipulate them. 3. Injection by object/method. Each instance and each method on that object can have a distinct sequence of injectors.